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Abstract 

SMT-based checking of refinement types for call-by-value lan¬ 
guages is a well-studied subject. Unfortunately, the classical trans¬ 
lation of refinement types to verification conditions is unsound un¬ 
der lazy evaluation. When checking an expression, such systems 
implicitly assume that all the free variables in the expression are 
bound to values. This property is trivially guaranteed by eager, but 
does not hold under lazy, evaluation. Thus, to be sound and precise, 
a refinement type system for Haskell and the corresponding verifi¬ 
cation conditions must take into account which subset of binders 
actually reduces to values. We present a stratified type system that 
labels binders as potentially diverging or not, and that (circularly) 
uses refinement types to verify the labeling. We have implemented 
our system in LiquidHaskell and present an experimental eval¬ 
uation of our approach on more than 10,000 lines of widely used 
Haskell libraries. We show that LiquidHaskell is able to prove 
96% of all recursive functions terminating, while requiring a mod¬ 
est 1.7 lines of termination-annotations per 100 lines of code. 

1. Introduction 

Refinement types encode invariants by composing types with SMT- 
decidable refinement predicates I27II37I . generahzing Floyd-Hoare 
Logic (e.g. Esc Java d) for functional languages. For example 

type Pos = {v:Int I v > 0} 

type Nat = {v:Int | v >= 0} 

are the basic type int refined with logical predicates that state 
that “the values” v described by the type are respectively strictly 
positive and non-negative. We encode pre- and postconditions 
(contracts) using refined function types like 

div :: n:Nat -> d:Pos -> {v:Nat | v <= n} 

which states that the function div requires inputs that are respec¬ 
tively non-negative and positive, and ensures that the output is less 
than the first input n. If a program containing div statically type- 
checks, we can rest assured that executing the program will not 
lead to any unpleasant divide-by-zero errors. By combining types 
and SMT based validity checking, refinement types have auto¬ 
mated the verification of programs with recursive datatypes, higher- 
order functions, and polymorphism. Several groups have used re¬ 
finements to statically verify properties ranging from simple array 
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safety M ED to functional correctness of data structures l20l . se¬ 
curity protocols a , and compiler correctness m. 

Given the remarkable effectiveness of the technique, we em¬ 
barked on the project of developing a refinement type based veri¬ 
fier for Haskell. The previous systems were all developed for eager, 
call-by-value languages, but we presumed that the order of evalua¬ 
tion would surely prove irrelevant, and that the soundness guaran¬ 
tees would translate to Haskell’s lazy, call-by-need regime. 

We were wrong. Our first contribution is to show that standard 
refinement systems crucially rely on a property of eager languages: 
when analyzing any term, one can assume that all the free vari¬ 
ables appearing in the term are bound to values. This property lets 
us check each term in an environment where the free variables are 
logically constrained according to their refinements. Unfortunately, 
this property does not hold for lazy evaluation, where free variables 
can be lazily substituted with arbitrary (potentially diverging) ex¬ 
pressions, which breaks soundness (jQ. 

The two natural paths towards soundness are blocked by chal¬ 
lenging problems. The first path is to conservatively ignore free 
variables except those that are guaranteed to be values e.g. by pat¬ 
tern matching, seq or strictness annotations. While sound, this 
leads to a drastic loss of precision. The second path is to explicitly 
reason about divergence within the refinement logic. This would be 
sound and precise - however it is far from obvious to us how to 
re-use and extend existing SMT machinery for this purpose. (S|8} 

Our second contribution is a novel approach that enables sound 
and precise checking with existing SMT solvers, using a stratified 
type system that labels binders as potentially diverging or not (<j4|. 
While previous stratified systems fTol would suffice for soundness, 
we show how to recover precision by using refinement types to 
develop a notion of terminating fixpoint combinators that allows the 
type system to automatically verify that a wide variety of recursive 
functions actually terminate (;|5j. 

Our third contribution is an extensive empirical evaluation of 
our approach on more than 10, 000 lines of widely used complex 
Haskell libraries. We have implemented our approach in LIQUID¬ 
HASKELL, an SMT based verifier for Haskell. LiquidHaskell is 
able to prove 96% of all recursive functions terminating, requiring 
a modest 1.7 lines of termination annotations per 100 lines of code, 
thereby enabling the sound, precise, and automated verification of 
functional correctness properties of real-world Haskell code (jj5). 

2. Overview 

We start with an overview of our contributions. After recapitulat¬ 
ing the basics of refinement types we illustrate why the classical 
approach based on verification conditions (VCs) is unsound due to 
lazy evaluation. Next, we step back to understand precisely how 
the VCs arise from refinement subtyping, and how subtyping is 
different under eager and lazy evaluation. In particular, we demon¬ 
strate that under lazy, but not eager, evaluation, the refinement type 
system, and hence the VCs, must account for divergence. Conse¬ 
quently, we develop a type system that accounts for divergence in 
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a modular and syntactic fashion, and illustrate its use via several 
small examples. Finally, we show how a refinement-based termi¬ 
nation analysis can be used to improve precision, yielding a highly 
effective SMT-based verifier for Haskell. 


2.1 Standard Refinement Types: From Subtyping to VC 

First, let us see how standard refinement type systems (21] (26) will 
use the refinement type aliases Pos and Nat and the specification 
for div from ^l]to accept good and reject bad. We use the syntax 
of Figure [I] where r is a rejinement expression, or just rejinement 
for short. We will vary the expressiveness of the language of refine¬ 
ments in different parts of the paper. 




:: Nat -> Nat 
y = let z = y + 


Nat 

y 


Int 


Refinement Subtyping To analyze the body of bad, the refinement 
type system will check that the second parameter y has type Pos at 
the call to div; formally, that the actual parameter y is a subtype of 
the type of div’s second input, via a subtyping query: 

| y > 0} h {y:Int 1 y - °> * < v:Int I v > °> 
We use the Abbreviations of Figure [T|to simplify the syntax of the 
queries. So the above query simplifies to: 

x:{x > 0}, y:{y > 0} h {v > 0} A {v > 0} 


Verification Conditions To discharge the above subtyping query, 
a refinement type system generates a verification condition (VC), 
a logical formula that stipulates that under the assumptions cor¬ 
responding to the environment bindings, the refinement in the sub- 
type implies the refinement in the super-type. We use the translation 
d • D shown in FigurefTJto reduce a subtyping query to a verification 
condition. The translation of a basic type into logic is the refine¬ 
ment of the type. The translation of an environment is the conjunc¬ 
tion of its bindings. Finally, the translation of a binding x :r is the 
embedding of t guarded by a predicate denoting that “x is a value”. 
For now, let us ignore this guard and see how the subtyping query 
for bad reduces to the classical VC: 

(x > 0) A (y > 0) =4- (v > 0) => (v > 0) 
Refinement type systems are carefully engineered (lj4| so that (un¬ 
like with full dependent types) the logic of refinements precludes 
arbitrary functions and only includes formulas from efficiently de¬ 
cidable logics, e.g. the quantifier-free logic of linear arithmetic and 
uninterpreted functions (QF-EUFLIA). Thus, VCs like the above 
can be efficiently validated by SMT solvers fTTl . In this case, the 
solver will reject the above VC as invalid meaning the implication, 
and hence, the relevant subtyping requirement does not hold. So the 
refinement type system will reject bad. 

On the other hand, a refinement system accepts good. Here, +’s 
type exactly captures its behaviour into the logic: 




Thus, we can conclude that the divisor z is a positive number. The 
subtyping query for the argument to div is 


x:{x > 0},y:{y > 0}, 
z:{z = y + 1} 

which reduces to the valid VC 
(x > 0) A (y > OJA 

(* = y + i) 


h{v = y+l} A{v>0} 

=» (v = y + 1) =F (v > 0) 


Refinements r 

::= 

...varies... 

Basic Types b 

::= 

{v:Int | r} | ... 

Types t 

::= 

6 | x:t -¥ t 

Environment V 

::= 

0 | x:t,T 

Subtyping 


T h Tl A T 2 

Abbreviations 

x:{r} 

= 

a::{a::Int | r} 

4*1 r} 

= 

{a;:Int | r} 

w 

= 

{v:Int | r} 

{x:{y.lat \ r y } \ r x } 

= 

{ablnt | r x A % \x/y]} 

Translation 

(jFF 6i A fe D 

= 


(K*:lnt | r}D 

= 

r 

^:{u:lnt | r}» 

= 

“x is a value” =>■ r [x/v] 

<|*:(»:7v->t)D 

= 

true 

0 Xt'.Tu . . . , X n :T n \) 

= 

flzFTiD A ... A (\x n :T n \) 


Figure 1. Notation: Types, Subtyping & VCs 


2.2 Lazy Evaluation Makes VCs Unsound 

To generate the classical VC, we ignored the “x is a value” guard 
that appears in the embedding of a binding dx:r|) (Figure [l|. 
Under lazy evaluation, ignoring this “is a value” guard can lead 
to unsoundness. Consider 

diverge :: Int -> {v:Int I false} 

The output type captures the post-condition that the function re¬ 
turns an int satisfying false. This counter-intuitive specifica¬ 
tion states, in essence, that the function does not terminate, i.e. 
does not return any value. Any standard refinement type checker 
(or Floyd-Hoare verifier like DafnjQ will verify the given signa¬ 
ture for diverge via the classical method of inductively assuming 
the signature holds for diverge and then guaranteeing the signa¬ 
ture (l6||23). Next, consider the call to div in explode: 

explode :: Int -> Int 

explode x = let {n = diverge 1; y = 0} 

To analyze explode, the refinement type system will check that y 
has type Pos at the call to div, i.e. will check that 

n:{f alse}, y:{y = 0} h {v = 0} F {v > 0} (1) 

In the subtyping environment n is bound to the type corresponding 
to the output type of diverge, and y is bound to the singleton 
type stating y equals 0. In this environment, we must prove that 
actual parameter’s type - i.e. that of y - is a subtype of Pos. The 
subtyping, using the embedding of Figure[T|and ignoring the “is a 
value” guard, reduces to the VC: 

false A y = 0 => (v = 0) => (v > 0) (2) 

The SMT solver proves this VC valid by using the contradiction in 
the antecedent, thereby unsoundly proving the call to div safe! 
Eager vs. Lazy Verification Conditions At this point, we pause 
to emphasize that the problem lies in the fact that the classical 


1 http://rise4fun.com/Dafny/wVGc 
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technique for encoding subtyping (or generally, Hoare’s “rule of 
consequence” CD) with VCs is unsound under lazy evaluation. 
To see this, observe that the VC (j2j is perfectly sound under eager 
(strict, call-by-value) evaluation. In the eager setting, the program is 
safe in that div is never called with the divisor 0, as it is not called 
at all! The inconsistent antecedent in the VC logically encodes the 
fact that, under eager evaluation, the call to div is dead code. Of 
course, this conclusion is spurious under Haskell’s lazy semantics. 
As n is not required, the program will dive headlong into evaluating 
the div and hence crash, rendering the VC meaningless. 

The Problem is Laziness Readers familar with fully dependently 
typed languages like Cayenne [D, Agda (24l, Coq 0, or Idris 0, 
may be tempted to attribute the unsoundness to the presence of ar¬ 
bitrary recursion and hence non-termination {e.g. diverge). While 
it is possible to define a sound semantics for dependent types that 
mention potentially non-terminating expressions m, it is not clear 
how to reconcile such semantics with decidable type checking. 

Refinement type systems avoid this situation by carefully re¬ 
stricting types so that they do not contain arbitrary terms (even 
through substitution), but rather only terms from restricted logics 
that preclude arbitrary user-defined functions £T3] [37] [37). Very 
much like previous work, we enforce the same restriction with a 
well-formedness condition on refinements (WF-Base-D in Fig.[6j. 

However, we show that this restriction is plainly not sufficient 
for soundness when laziness is combined with non-termination, as 
binders can be bound to diverging expressions. Unsurprisingly, in a 
strongly normalizing language the question of lazy or strict seman¬ 
tics is irrelevant for soundness, and hence an “easy” way to solve 
the problem would be to completely eliminate non-termination and 
rely on the soundness of previous refinement or dependent type sys¬ 
tems! Instead, we show here how to recover soundness for a lazy 
language without imposing such a drastic requirement. 

2.3 Semantics, Subtyping & Verification Conditions 

To understand the problem, let us take a step back to get a clear 
view of the relationship between the operational semantics, sub¬ 
typing, and verification conditions. We use the formulation of 
evaluation-order independent refinement subtyping developed for 
X H ED in which refinements r are arbitrary expressions e from 
the source language. We define a denotation for types and use it to 
define subtyping declaratively. 

Denotations of Types and Environments Recall the type Pos de¬ 
fined as {v:lnt I 0 < v}. Intuitively, Pos denotes the set of Int 
expressions which evaluate to values greater than 0. We formalize 
this intuition by defining the denotation of a type as: 

1{x:t [ r}] A {e | 0 I- e : t, if e w then r [w/x] M-* true} 

That is, the type denotes the set of expressions e that have the 
corresponding base type r which diverge or reduce to values that 
make the refinement true. The guard e w is crucially required 
to prove soundness in the presence of recursion. Thus, quoting EH . 
“refinement types specify partial and not total correctness”. 

An environment T is a sequence of type bindings, and a closing 
substitution 9 is a sequence of expression bindings: 

r A Xx'.Tl, . . . Xn'.Tn 9 = Xl l-A e \, . . . , Xn l-A e„ 

Thus, we define the denotation of F as the set of substitutions: 

IF] A {0 | Vx:r e r.0(z) e I0(r)]} 

Declarative Subtyping Equipped with interpretations for types and 
environments, we define the declarative subtyping A-Base (over 
basic types b, shown in Figure [T) to be containment between the 


types’ denotations: 

V0 £ in. [0({v:B I ri»] C {9{{v.B I r 2 »I 
T h {v.B | n} A {v.B | r 2 } 

Let us revisit the explode example from §2.2| recall that the func¬ 
tion is safe under eager evaluation but unsafe under lazy evaluation. 
Let us see how the declarative subtyping allows us to reject in the 
one case and accept in the other. 

Declarative Subtyping with Lazy Evaluation Let us revisit the 
query |l) to see whether it holds under the declarative subtyping 
rule A-BASE. The denotation containment 

MQ €[n:{false}, y:{y = O}].[0 (v = 0}] C [0 (v > 0}] (3) 
does not hold. To see why, consider a 9 that maps n to any diverging 
expression of type Int and y to the value 0. Then, 0 € \9 {v = 0}] 
but 0 0 \9 {v > 0}], thereby showing that the denotation contain¬ 
ment does not hold. 

Declarative Subtyping with Eager Evaluation Since denotational 
containment { 3 } does not hold, X H cannot verify explode under 
eager evaluation. However, Belo et al. 0 note that under eager 
(call-by-value) evaluation, each binder in the environment is only 
added after the previous binders have been reduced to values. 
Hence, under eager evaluation we can restrict the range of the 
closing substitutions to values (as opposed to expressions). Let us 
reconsider |3) in this new light: there is no value that we can map 
n to, so the set of denotations of the environment is empty. Hence, 
the containment ([5) vacuously holds under eager evaluation, which 
proves the program safe. Belo’s observation is implicitly used by 
refinement types for eager languages to prove that the standard (i.e. 
under call-by-value) reduction from subtyping to VC is sound. 
Algorithmic Subtyping via Verification Conditions The above 
subtyping (A-Base) rule allows us to prove preservation and 
progress ED but quantifies over evaluation of arbitrary expres¬ 
sions, and so is undecidable. To make checking algorithmic we 
approximate the denotational containment using verification con¬ 
ditions (VCs), formulas drawn from a decidable logic, that are valid 
only if the undecidable containment holds. As we have seen, the 
classical VC is sound only under eager evaluation. Next, let us use 
the distinctions between lazy and eager declarative subtyping, to 
obtain both sound and decidable VCs for the lazy setting. 

Step 1: Restricting Refinements To Decidable Logics Given that in 
X H refinements can be arbitrary expressions, the first step towards 
obtaining a VC, regardless of evaluation order, is to restrict the 
refinements to a decidable logic. We choose the quantifier free 
logic of equality, uninterpreted functions and linear arithmetic (QF- 
EUFLIA). We design our typing rules to ensure that for any valid 
derivation, all the refinements belong in this restricted language. 
Step 2: Translating Containment into VCs Our goal is to encode 
the denotation containment antecedent of A-Base 

V0 € \Tj. \9{{v:B | n})] C {0{{v.B \ r 2 })] (4) 

as a logical formula, that is valid only when the above holds. Intu¬ 
itively, we can think of the closing substitutions 9 as corresponding 
to assignments<\9\) of variables X of the VC. We use the variable 
x to approximate denotational containment by stating that if x be¬ 
longs to the type {v.B | n} then x belongs to the type {v.B r 2 }: 

VX € dom(T), x.(]r[) => (\x:{v:B | n}D =* <\x:{v.B | r 2 }[) 
where (]r[) and (]2::r[) are respectively the translation of the envi¬ 
ronment and bindings into logical formulas that are only satisfied 
by assignments (]0|) as shown in Figure[l] Using the translation of 
bindings, and by renaming x to v, we rewrite the the condition as 
VX 6 dom( T), u.flri) => (“v is a value” =>■ n) 

=> (“v is a value” =>■ P2) 
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Type refinements are carefully chosen to belong to the decidable 
logical sublanguage QF-EUFLIA, thus we directly translate type 
refinements into the logic. Thus, what is left is to translate into 
logic the environment and the “is a value” guards. We postpone 
translation of the guards as we approximate the above formula by a 
stronger, i.e. sound with respect to[4] VC that just omits the guards: 

VX g dom( r), u.flri) => n r 2 
To translate environments, we conjoin their bindings’ translations: 

(k:n, • • ■, x n :r n \) = fla^nD A ... A <\x n \r n D 
However, since types denote partial correctness, the translations 
must also explicitly account for possible divergence: 

(x:{n:Int | r}|) = “x is a value” ^ r [x/v\ 

That is, we cannot assume that each x satisfies its refinement r; we 
must guard that assumption with a predicate stating that x is bound 
to a value (not a diverging term.) 

The crucial question is: how can one discharge these guards to 
conclude that x indeed satisfies r? One natural route is to enrich the 
refinement logic with a predicate that states that “x is a value”, and 
then use the SMT solver to explicitly reason about this predicate 
and hence, divergence. Unfortunately, we show in [|8] that such 
predicates lead to three-valued logics, which fall outside the scope 
of the efficiently decidable theories supported by current solvers. 
Hence, this route is problematic if we want to use existing SMT 
machinery to build automated verifiers for Haskell. 


2.4 Our Answer: Implicit Reasoning About Divergence 

One way forward is to implicitly reason about divergence by elimi¬ 
nating the “x is a value” guards (i.e. value guards) from the VCs. 
Implicit Reasoning: Eager Evaluation Under eager evaluation 
the domain of the closing substitutions can be restricted to val¬ 
ues (3). Thus, we can trivially eliminate the value guards, as they 
are guaranteed to hold by virtue of the evaluation order. Returning 
to explode, we see that after eliminating the value guards, we get 
the VC |2) which is, therefore, sound under eager evaluation. 
Implicit Reasoning: Lazy Evaluation However, with lazy evalua¬ 
tion, we cannot just eliminate the value guards, as the closing sub¬ 
stitutions are not restricted to just values. Our solution is to take 
this reasoning out of the hands of the SMT logic and place it in 
the hands of a stratified type system. We use a non-deterministic 
ft -reduction (formally defined in to label each type as: A Div- 

type, written r, which are the default types given to binders that 
may diverge, or, a Wnf-type, written -H", which are given to binders 
that are guaranteed to reduce, in a finite number of steps, to Haskell 
values in Weak Head Normal Form (WHNF). Up to now we only 
discussed Int basic types, but our theory supports user-defined al¬ 
gebraic data types. An expression like 0 : repeat 0 is an infinite 
Haskell value. As we shall discuss, such infinite values cannot be 
represented in the logic. To distinguish infinite from finite values, 
we use a Fin-type, written r 1 - 1 , to label binders of expressions that 
are guaranteed to reduce to finite values with no redexes. This strat¬ 
ification lets us generate VCs that are sound for lazy evaluation. Let 
B be a basic labelled type. The key piece is the translation of envi¬ 
ronment bindings: 


(!*:{«* I r }D 


Jtrue, if B is a Div type 
| r \x/v\ , otherwise 


That is, if the binder may diverge, we simply omit any constraints 
for it in the VC, and otherwise the translation directly states (i.e. 
without the value guard) that the refinement holds. Returning to 
explode, the subtyping query |T| yields the invalid VC 
true =>v = 0=>v>0 


and so explode is soundly rejected under lazy evaluation. 


As binders appear in refinements, and binders may refer to 
potentially infinite computations (e.g. [ 0 . . ]), we must ensure that 
refinements are well defined (i.e. do not diverge). We achieve this 
via stratification itself, i.e. by ensuring that all refinements have 
type Bool 1 - 1 . By Corollary [T| this suffices to ensure that all the 
refinements are indeed well-defined and converge. 


2.5 Verification With Stratified Types 

While it is reassuring that the lazy VC soundly rejects unsafe 
programs like explode, we now demonstrate by example that 
it usefully accepts safe programs. First, we show how the basic 
system - all terms have Div types - allows us to prove “partial 
correctness” properties without requiring termination. Second, we 
show how to extend the basic system by using Haskell’s pattern 
matching semantics to assign the pattern match scrutinees Wnf 
types, thereby increasing the expressiveness of the verifier. Third, 
we show how to further improve the precision and usability of the 
system by using a termination checker to assign various terms Fin 
types. Fourth, we close the loop, by illustrating how the termination 
checker can itself be realized using refinement types. Finally, we 
use the termination checker to ensure that all refinements are well- 
defined (i.e. do converge.) 

Example: VCs and Partial Correctness The first example illus¬ 
trates how, unlike Curry-Howard based systems, refinement types 
do not require termination. That is, we retain the Floyd-Hoare 
notion of “partial correctness”, and can verify programs where 
all terms have Div-types. Consider exi which uses the result of 
collatz as a divisor. 

exl :: Int -> int 
exl n = let x = collate n in 

collatz :: Int -> (v:Int I v 
collatz a 

| even n = collatz (n / 

I otherwise = collatz (3*n 



The jury is still out on whether the collatz function terminates, 
but it is easy to verify that its output is a Div int equal to 1 . At 
the call to div the parameter x has the output type of collatz, 
yielding the subtyping query: 

x:{v:Int|v = l}h{v=l}A{v>0} 
where the sub-type is just the type of x. As Int is a Div type, the 
above reduces to the VC (true a# v = 1 =t- v>0) which the 
SMT solver proves valid, thereby verifying exl. 

Example: Improving Precision By Forcing Evaluation If all 
binders in the environment have Div-types then, effectively, the 
verifier can make no assumptions about the context in which a term 
evaluates, which leads to a drastic loss of precision. Consider: 
ex2 = let {x = 1; y = inc x} in 10 'div' y 
inc :: z:Int -> {v:Int I v > z } 


The call to div in ex2 is obviously safe, but the system would 
reject it, as the call yields the subtyping query: 

x:{x:Int | x = 1}, y:{y:Int | y > x} b {v > x} A {v > 0} 
Which, as x is a Div type, reduces to the invalid VC 

We could solve the problem by forcing evaluation of x. In Haskell 
the seq operator or a bang-pattern can be used to force evaluation. 
In our system the same effect is achieved by the case-of primitive: 
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inside each case the matched binder is guaranteed to be a Haskell 
value in WHNF. This intuition is formalized by the typing rule (T- 
Case-D), which checks each case after assuming the scrutinee and 
the match binder have Wnf types. 

If we force x’s evaluation, using the case primitive, the call to 
div yields the subtyping query: 


x:{x:Int* | x = 1} 
y:{y:Int | y > x} 


{v>x}A{v>0} 


(5) 


As x is Wnf, we accept ex2 by proving the validity of the VC 


x = l=>v>x=£-v>0 (6) 


Example: Improving Precision By Termination While forcing 
evaluation allows us to ensure that certain environment binders 
have non-Div types, it requires program rewriting using case¬ 
splitting or the seq operator which leads to non-idiomatic code. 

Instead, our next key optimization is based on the observation 
that in practice, most terms don’t diverge. Thus, we can use a 
termination analysis to aggressively assign terminating expressions 
Fin types, which lets us strengthen the environment assumptions 
needed to prove the VCs. For example, in the ex2 example the 
term 1 obviously terminates. Hence, we type x as Int*. yielding 
the subtyping query for div application: 


x:{x:lnt^ | x = 1} 
y:{y:!nt | y > x} 


b {v > x} A {v > 0} 


(7) 


As x is Fin, we accept ex2 by proving the validity of the VC 


> 0 


( 8 ) 


Example: Verifying Termination With Refinements While it is 
straightforward to conclude that the term l does not diverge, how 
do we do so in general? For example: 

ex4 = let {x = f 9; y = inc x} in 10 'div' y 

* :: Nat -> {vMBtfc 1 v = 1} 

f n = if n == 0 then 1 else f (n-1) 

We check the call to div via subtyping query ([7} and VC (8), which 
requires us to prove that f terminates on all Nat* inputs. 

We solve this problem by showing how refinement types may 
themselves be used to prove termination, by following the classical 
recipe of proving termination via decreasing metrics ll32l as em¬ 
bodied in sized types mm. The key idea is to show that each 
recursive call is made with arguments of a strictly smaller size, 
where the size is itself a well founded metric, e.g. a natural number. 

We formalize this intuition by type checking recursive proce¬ 
dures in a termination-weakened environment where the procedure 
itself may only be called with arguments that are strictly smaller 
than the current parameter (using terminating fixpoints of §4,2| ) 
For example, to prove f terminates, we check its body in an envi¬ 
ronment 

n : Nat* f : {n':Nat* | n' < n} ->• {v = 1} 
where we have weakened the type of f to stipulate that it only be 
(recursively) called with Nat values n' that are strictly less than 
the (current) parameter n. The argument of f exactly captures these 
constraints, as using the Abbreviations of Figure[T|the argument of 
f is expanded to {n':Int* | n' < n A n' >= 0}. The body type- 
checks as the recursive call generates the valid VC 

0 < n A -i(0 = n)=>v = n—l=>(0<v<n) 


Example: Diverging Refinements In this final example we discuss 
why refinements should always converge and how we statically 
ensure convergence. Consider the invalid specification 


Definition 

def 

::= measure / :: r 



eqi■■■ eq„ 

Equation 

eq 

::= f(Dx) = r 

Equation to 

Type 


d / (Dx) 

= r|) 

= D::xvf-y{^.r\fv = r} 


Figure 2. Syntax of Measures 


that states that the value of a diverging integer is 12. The above 
specification should be rejected, as the refinement v = 12 does not 
evaluate to true (diverge 0 = 12 fy* true), instead it diverges. 

We want to check the validity of the formula v = 12 under a 
model that maps v to the diverging integer diverge 0. Any system 
that decides this formula to be true will be unsound, i.e. the VCs 
will not soundly approximate subtyping. For similar reasons, the 
system should not decide that this formula is false. To reason about 
diverging refinements one needs three valued logic, where logical 
formulas can be solved to true, false, or diverging. Since we want to 
discharge VC using SMT solvers that currently do not support three 
valued reasoning, we exclude diverging refinements from types. To 
do so, we restrict = to finite integers 

= :: Int* —> Int* —> Bool* 

and we say that { v: B | r} is well-formed iff r has a Bool* type 
(Corollary [lj. Thus the initial invalid specification will be rejected 
as non well-formed. 

2.6 Measures: From Integers to Data Types 

So far, all our examples have used only integer and boolean expres¬ 
sions in refinements. To describe properties of algebraic data types, 
we use measures, introduced in prior work on Liquid Types (20). 
Measures are inductively defined functions that can he used in re¬ 
finements, and provide an efficient way to axiomatize properties of 
data types. For example, emp determines whether a list is empty: 
measure emp :: [Int] -> Bool 
emp (x:xs) = false 

The syntax for measures deliberately looks like Haskell, but it is 
far more restricted, and should really be considered as a separate 
language. A measure has exactly one argument, and is defined by 
a list of equations, each of which has a simple pattern on the left 
hand side (see Figure [2). The right-hand side of the equation is a 
refinement expression r. Measure definitions are typechecked in 
the usual way; we omit the typing rules which are standard. (Our 
metatheory does not support type polymorphism, so in this paper 
we simply reason about lists of integers; however, our implementa¬ 
tion supports polymorphism.) 

Denota tiona l semantics The denotational semantics of types in 
X H in j ]2.3| is readily extended to support measures. In \ H a re¬ 
finement r is an arbitrary expression, and calls to a measure are 
evaluated in the usual way by pattern matching. For example, with 
the above definition of emp it is straightforward to show that 

[1,2,3]:: {v:[lnt] | not (emp v)} (9) 

as the refinement not (emp ([1, 2, 3] )) evaluates to true. 
Measures as Axioms How can we reason about invocations of 
measures in the decidable logic of VCs? A natural approach is 
to treat a measure like emp as an uninterpreted function, and add 
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logical axioms that capture its behaviour. This looks easy: each 
equation of the measure definition corresponds to an axiom, thus: 

emp [] = true 

Vx, xs. emp (x : xs) = false 
Under these axioms the judgement|9]is indeed valid. 

Measures as Refinements in Types of Data Constructors Axiom- 
atizing measures is precise', that is, the axioms exactly capture the 
meaning of measures. Alas, axioms render SMT solvers inefficient, 
and render the VC mechanism unpredictable, as one must rely on 
various brittle syntactic matching and instantiation heuristics fT2l . 

Instead, we use a different approach that is both precise and 
efficient. The key idea is this: instead of translating each measure 
equation into an axiom, we translate each equation into a refined 
type for the corresponding data constructor 1201 . This translation 
is given in Figure[2] For example, the definition of the measure emp 
yields the following refined types for the list data constructors: 

[] :: {v:[lnt] | emp v = true} 

x:Int xs:[lnt] —} {v:[lnt] | emp v = false} 

These types ensure that: (1) each time a list value is constructed, 
its type carries the appropriate emptiness information. Thus our 
system is able to statically decide that |9]l is valid, and, (2) each 
time a list value is matched, the appropriate emptiness information 
is used to improve precision of pattern matching, as we see next. 
Using Measures As an example, we use the measure emp to pro¬ 
vide an appropriate type for the head function: 


head :: (v:[Int] I not (emp t 


head is safe as its input type stipulates that it will only be called 
with lists that are not [ ], and so error " ..." is dead code. The 
call to error generates the subtyping query 


xs:{xs:[lnt] J ' | -.(emp xs)} 
b:{b:[lnt]'*' | (emp xs) = true} 


b {true} A {false} 


The match-binder b holds the result of the match f30j . In the 
[ ] case, we assign it the refinement of the type of [ ] which 
is (emp xs) = true. Since the call is done inside a case-of 
expressions both xs and b are guaranteed to be in WHNF, thus 
they have Wnf types. 

The verifier accepts the program as the above subtyping reduces 
to the valid VC 


-.(emp xs) A ((emp xs} — true) =4- true => false 

Consequently, our system can naturally support idiomatic Haskell, 
e.g. taking the head of an infinite list: 

ex x = head (repeat x) 

repeat :: Int -> {v:[Int] I not (emp v)} 
repeat y = y : repeat y 


Multiple Measures If a type has multiple measures, we simply 
refine each data constructor’s type with the conjunction of the 
refinements from each measure. For example, consider a measure 
that computes the length of a list: 

measure len :: [Int] -> Int 
len ( [] ) =0 

len (x:xs) = 1 + len xs 


Constants 

c ::= 0,1,-1,... | true, false 

| | =,<,... | crash 

Values 

w ::= c | Xx.e \ De 

Expressions 

| case x = e of {D x —>■ e} 

Refinements 

r ::= e 

Basic Types 

B :\= Int | Bool | T 

Types 

r ::= {v:B \ r} \ x:r -A r 

Contexts 

C ::= .\Ce\cC\ DeCe 
| case x = C of {D y ej 

Reduction 

CM ^ C[e'] ife^e' 

cv c —^ S(c,v) 

(Xx.e) e x ^ e \e x /x\ 
let x = e x in e -A e \e x /x\ 

case a; = 1% 

e of {Di yt -A ef} ej [Dj e/x][e/yj] 


Figure 3. X u : Syntax and Operational Semantics 


Using the translation of Figure[2] we extract the following types for 
list’s data constructors. 

[] :: {v:[lnt] | len v = 0} 

x:Int —y xs:[lnt] —> {v:[lnt] | len v = 1 + (len xs)} 
The final types for list data constructors will be the conjunction of 
the refinements from len and emp: 

[] :: {v:[lnt] | emp v = true A len v = 0} 

x:Int —> xs:[lnt] —> 

{v:[lnt] | emp v = false A len v ss t + (len xs)} 

3. Declarative Typing: X u 

Next, we formalize our stratified refinement type system, in two 
steps. First, in this section, we present a core calculus X u , with a 
general /3-reduction semantics. We describe the syntax, operational 
semantics, and sound but undecidable declarative typing rules for 
X u . Second, in fj4] we describe QF-EUFLIA, a subset of X u that 
forms a decidable logic of refinements, and use it to obtain X D with 
decidable SMT-based algorithmic typing. 

3.1 Syntax 

Figureplsummarizes the syntax of X u , which is essentially the cal¬ 
culus A” ED without the dynamic checking features (like casts), 
but with the addition of data constructors. In X u , as in X H , refine¬ 
ment expressions r are not drawn from a decidable logical sublan¬ 
guage, but can be arbitrary expressions e (hence r ::= e in Fig¬ 
ure [3}. This choice allows us to prove preservation and progress, 
but renders typechecking undecidable. 

Constants The primitive constants of X u include true, false, 0, 
1, —1, etc., and arithmetic and logical operators like +, —, <,/, A, 
-.. In addition, we include a special untypable constant crash that 
models “going wrong”. Primitive operations return a crash when 
invoked with inputs outside their domain, e.g. when / is invoked 
with 0 as the divisor, or when assert is applied to false. 

Data Constructors We encode data constructors as special con¬ 
stants. Each data type has an arity Arity(T) that represents the ex¬ 
act number of data constructors that return a value of type T. For 
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example the data type [Int], which represents lists of integers, has 
two data constructors: [] and i.e. has arity 2. 

Values & Expressions The values of X u include constants, A- 
abstractions Xx.e, and fully applied data constructors D that wrap 
expressions. The expressions of X u include values, as well as 
variables x, applications e e, and the case and let expressions. 

3.2 Operational Semantics 

Figure [3] summarizes the small step contextual /3-reduction seman¬ 
tics for X u . Note that we allow for reductions under data construc¬ 
tors, and thus, values may be further reduced. We write e ^ e' if 
there exist ei,..., ej such that e is ei, e' is ej and Vi, j, 1 < i < j, 
we have e,; <-* e»+i. We write e °4* e' if there exists some (finite) 
j such that e e!. 

Constants Apphcation of a constant requires the argument be re¬ 
duced to a value; in a single step the expression is reduced to the 
output of the primitive constant operation. For example, consider 
=, the primitive equality operator on integers. We have 5(=, n) = 
— n where 5(= n ,m ) equals true iff m is the same as n. 


Well-Formedness 

r, v:B b u r : Bool 


1^1 


r h u {v.B I r} 

rbu-Ti r,x:r x \-ur 
r h u x:r x -4 T 


[£h^ 


r h u {v.B I 7-1} X {v.B I r 2 } 

BY- v t x <t x T,x:t' x \-ut 


{x,r)eV 


b-FUN 

l rh “ e;T l 

- T-CON 


3.3 Types 

X u types include basic types, which are refined with predicates, 
and dependent function types. Basic types B comprise integers, 
booleans, and a family of data-types T (representing lists, trees 
etc..) For example the data type [Int] represents lists of integers. 
We refine basic types with predicates (boolean valued expressions 
e) to obtain basic refinement types {v.B \ ej. Finally, we have 
dependent function types x:t x -4 r where the input x has the type 
r :r and the output r may refer to the input binder x. 

Notation We write B to abbreviate {v.B | true}, and t x —> t to 
abbreviate x:t x —> r if x does not appear in r. We use _ for unused 
binders. We write (u:nat i | r} to abbreviate (mint* | 0 < v A r}. 
Denotations Each type r denotes a set of expressions [r], that are 
defined via the dynamic semantics (21). Let |_tJ be the type we 
get if we erase all refinements from r and e: [rj be the standard 
typing relation for the typed lambda calculus. Then, we define the 
denotation of types as: 

l{x:B | r}] = {e | e:B, if e <-4* w then r [w/x] M-* true} 
[*:% -4r] = (e l e:{r x -4 rj.Ve. 6 [r B ], e e, € [t [e x /x]}} 


Constants For each constant c we define its type Ty(c) such that 
c £ [Ty(c)J. For example. 


Ty(3) 

Ty(+) 

Ty(/) 

Ty(error r ) 


{v:Int | v = 3} 

x:Int -4 y:Int —y {v:Int | v = x + y} 
Int —y (v:Int | v > 0} -4 Int 
(v:Int | false} —y r 


T h u Xx.e : ( x:t x -4 r) 

T \~u ei : (x:t x -4 r) r \~ v e 2 : t x 
r hu ei e 2 : r [e 2 /x] 

r \~y e x : t x T, x:t x Fy e : r F i u r 
T \~u let x = e x in e : r 


T\- v e\ {v.T | r} Fife r 
Vi.Vy(D l )=WfJ^{v.T\r,} 
V,WB^--W-T\r/\n}^ v ei -.r 
T h v case x = ea£{DiVJ-yei}:T 


T-Case 


Figure 4. Type-checking for X u 


3.4 Type Checking 

Next, we present the type-checking judgments and rules of X u . 
Environments and Closing Substitutions A type environment T 
is a sequence of type bindings x\:ti,..., x n :T n . An environment 
denotes a set of closing substitutions 0 which are sequences of 
expression bindings: xi 1-4 ei,..., x n h4 e n such that: 

PI m {0 | \/x:t 6 l\0(z) € [fl(r)]} 


So, by definition we get the constant typing lemma 
Lemma 1. [Constant Typing] Every constant c 6 [Ty(c)J. 

Thus, if Ty(c) A x:t x -4 r, then for every value w £ [r*], 
we require that S(c, w) 6 [r [w/x]]. For every value w ^ [r x ], it 
suffices to define S(c,w ) as crash, a special untyped value. 

Data Constructors The types of data constructor constants are 
refined with predicates that track the semantics of the measures 
associated with the data type. For example, as discussed in §2.6| we 
use emp to refine the list data constructors’ types: 

T y(0) *= (v:[Int] | emp v} 

Ty(:) = Int -4 [Int] -4 (v:[lnt] | -i(emp v)} 

By construction it is easy to prove that Lemma |T| holds for data 
constructors. For example, emp [] goes to true. 


Judgments We use environments to define three kinds of rules: 
Well-formedness, Subtyping, and Typing mm. A judgment r ha 
t states that the refinement type r is well-formed in the environ¬ 
ment r. Intuitively, the type r is well-formed if all the refinements 
in t are Bool-typed in T. A judgment T ha Ti 4 r 2 states that the 
type ti is a subtype of r 2 in the environment T. Informally, n is 
a subtype of r 2 if, when the free variables of n and r 2 are bound 
to expressions described by T, the denotation of n is contained in 
the denotation of r 2 . Subtyping of basic types reduces to denota- 
tional containment checking. That is, for any closing substitution 6 
in the denotation of F, for every expression e, if e £ [<9(n)] then 
e £ [#(r 2 )]. A judgment V ha e : r states that the expression e 
has the type r in the environment T. That is, when the free vari¬ 
ables in e are bound to expressions described by T, the expression 
e will evaluate to a value described by r. 
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Expressions, Values, Constants, Basic types: see Figure[3] 


Types 

T : 

1 

{v.B | r} | {v.B 1 | r} 

Labels 

l : 

= 

m 

Refinements 

r : 

= 

p 

Predicates 

p : 

1 

1 

p = p | p <p | pAp | -.p 
n | x | fp | p®p 

true | false 

Measures 

f,9,h 



Operators 

® 

= 

+I-I--- 

Integers 

n 

= 

0 | 1 | -1 | ... 

Domain 

d 

= 

n | Cw | D d | true | false 

Model 

a 

= 

x\ i ^ d\ ,..., Xn i ^ dn 

Lifted Values 

W± 

= 

c \ Xx.e | i>||e'|A 

Figure 5. Syntax of X D 


Soundness Following X H (21], we use the (undecidable) A-Base 
to show that each step of evaluation preserves typing, and that if an 
expression is not a value, then it can be further evaluated: 

• Preservation: If 0 \~u e : r and e e', then 0 \~u e! : r. 

• Progress: If 0 her e : r and e/», then e e'. 

We combine the above to prove that evaluation preserves typing, 
and that a well typed term will not crash. 

Theorem 1. [Soundness of \ u ] 

• Type-Preservation: If 0 he/ e : t, e w tAen 0 he/ iu : r. 

• Crash-Freedom: Iff/) h u e : t then e crash. 

We prove the above following the overall recipe of EQ Crash- 
freedom follows from type-preservation and as crash has no type. 
The Substitution Lemma, in particular, follows from a connection 
between the typing relation and type denotations: 

Lemma 2. [Denotation Typing] If 0 \~u e : r then e 6 [t], 

4. Algorithmic Typing: \ D 

While X u is sound, it cannot be implemented thanks to the undecid¬ 
able denotational containment rule A-Base (Figure |4j. Next, we 
go from X u to X D , a core calculus with sound, SMT-based algo¬ 
rithmic type-checking in four steps. First, we show how to restrict 
the language of refinements to an SMT-decidable sub-language QF- 
EUFLIA (j |4.1| >. Second, we stratify the types to specify whether 
their inhabitants may d iverg e, must reduce to values, or must re¬ 
duce to finite values ( §4.2| ). Third, we show how to enforce the 
stratification by encoding recursion using special fixpoint combi- 
nator constants ( §4.2| >. Finally, we show how to use QF-EUFLIA 
and the stratification to approximate the undecidable A-Base with 
a decidable verification con ditio n A-BASE-D, thereby obtaining 
the algorithmic system X D (t |4.3| . 

4.1 Refinement Logic: QF-EUFLIA 

Figure [5] summarizes the syntax of X D . Refinements r are now 
predicates p, drawn from QF-EUFLIA, the decidable logic of 
equality, uninterpreted functions and linear arithmetic (22]. Pred¬ 
icates p include linear arithmetic constraints, function application 
wher e function symbols correspond to measures (as described in 
§2.6| >, and boolean combinations of sub-predicates. 


All rules as in Figure[4]except as follows: 
Well-Formedness 

r, v:B \~r> p : Bool^ 


r h n {v:B I p} 


Subtyping 


1 ^ 7-2 | 


flr,u : gp (|pi[) dp 2 D is valid 
rb D {v:B\ Pl }<{v:B\p 2 } 


rbs» 


r) r hoy 

:r[y/x] 


l*UW}=>TisDiv 
rh D e: { v:T l | r} T r 

Vi.Ty(A) = yjrj -A {v:T \ r<} 
T, yy.Tj, x:{v:T^ \ r A n} \- D e t : t 


rh D 


x = eof {Di Vj - 


et}: 


Figure 6. Typechecking for X J 


Well-Formedness For a predicate to be well-formed it should be 
boolean and arithmetic operators should be applied to integer terms, 
measures should be applied to appropriate arguments (i.e. emp is 
applied to [Int]), and equality or inequality to basic (integer or 
boolean) terms. Furthermore, we require that refinements, and thus 
measures, always evaluate to a value. We capture these require¬ 
ments by assigning appropriate types to operators and measure 
functions, after which we require that each refinement r has type 
Bool^ (rule WF-Base-D in Figure[6]l. 

Assignments Figure [5] defines the elements d of the domain V of 
integers, booleans, and data constructors that wrap elements from 
D. The domain D also contains a constant c w for each value w 
of X u that does not otherwise belong in T> (e.g. functions or other 
primitives). An assignment o is a map from variables to V. 
Satisfiability & Validity We interpret boolean predicates in the logic 
over the domain T>. We write o |= p if a is a model of p. We omit 
the formal definition for space. A predicate p is satisfiable if there 
exists o \= p. A predicate p is valid if for all assignments a [= p. 
Connecting Evaluation and Logic To prove soundness, we need to 
formally connect the notion of logical models with the evaluation 
of a refinement to true. We do this in several steps, briefly outlined 
for brevity. First, we introduce a primitive bottom expression _L 
that can have any Div type, but does not evaluate. Second, we 
define lifted values w ± (Figure^, which are values that contain _L. 
Third, we define lifted substitutions 0 ± , which are mappings from 
variables to lifted values. Finally, we show how to embed a lifted 
substitution 9 ± into a set of assignments (]6f L |) where, intuitively 
speaking, each _L is replaced by some arbitrarily chosen element of 
V. Now, we can connect evaluation and logical satisfaction: 

Theorem 2. Iff/) \~o O 1 ' (p) : Bool'* 1 ', then 

0 X (p)-4* tru e iff \/oe <16^.0 \=p 

Restricting Refinements to Predicates Our goal is to restrict 
A-Base so that only predicates from the decidable logic QF- 
EUFLIA (not arbitrary expressions) appear in implications QrD =t- 
{u:6[ pi} =£- {v:b \ p 2 }. Towards this goal, as shown in Figures[5] 
and [6] we restrict the syntax and well-formedness of types to con- 
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tain only predicates, and we convert the program to ANF after 
which we can restrict the application rule T-APP-D to applications 
to variables, which ensures that refinements remain within the logic 
after substitution m Recall, that this is not enough to ensure that 
refinements do converge, as under lazy evaluation, even binders 
can refer to potentially divergent values. 

4.2 Stratified Types 

The typing rules for X D are given in Figure [H] Instead of explicitly 
reasoning about divergence or strictness in the refinement logic, 
which leads to significant theoretical and practical problems, as 
discussed in ^8] we choose to reason implicitly about divergence 
within the type system. Thus, the second critical step in our path to 
\ D is the stratification of types into those inhabited by potentially 
diverging terms, terms that only reduce to values, and terms which 
reduce to finite values. Furthermore, the stratification crucially 
allows us to prove Theorem [2] which requires that refinements 
do not diverge ( e.g. by computing the length of an infinite list) 
by ensuring that inductively defined measures are only applied 
to finite values. Next, we describe how we stratify types with 
labels, and then type the various constants, in particular the fixpoint 
combinators, to enforce stratification. 

Labels We specify stratification using two labels for types. The 
label l (resp. JJ.) is assigned to types given to expressions that 
reduce (using /3-reduction as defined in Figure[3} to a value w (resp. 
finite value, i.e. an element of the inductively defined T>). Formally, 

Wnf types l{v:B l | r}] = \{v:B | r}Jf) {e | e *-A* w} (10) 

Fin types [{■u:.B* | r}] = \{v.B | r||f) {e | e <A-* d} (11) 

Unlabelled types are assigned to expressions that may diverge. Note 
that for any B and refinement r we have 

l{v:B * | r}j C [{ v.B * | r}] C [{ v:B | r}] 

The first two sets are equal for Int and Bool, and unequal for 
(lazily) constructed data types T. We need not stratify function 
types {i.e. they are Div types) as binders with function types do 
not appear inside the VC, and are not applied to measures. 
Enforcing Stratification We enforce stratification in two steps. 
First, the T-Case-D rule uses the operational semantics of case- 
of to type-check each case in an environment where the scrutinee x 
is assumed to have a Wnf type. All the other rules, not mentioned 
in Figure [6] remain the same as in Figure [4] Second, we create 
stratified variants for the primitive constants and separate fixpoint 
combinator constants for (arbitary, potentially non-terminating) re¬ 
cursion (fix) and bounded recursion (tf ix). 

Stratified Primitives First, we restrict the primitive operators whose 
output types are refined with logical operators, so they are only 
invoked on finite arguments (so that the corresponding refinements 
are guaranteed to not diverge). 

Ty(n) = {n:Int* | v = n} 

Ty(-) = x:B^ -a y:B 4 -A {n:Bool* | v x = y} 

Ty(+) = a;:Int* -A r/:Int* -A {n:Int* | v = x + y} 

Ty(A) = a;:Bool* —> y:Bool* —> {n:Bool* | v x A y} 

It is easy to prove that the above primitives respect their stratifica¬ 
tion labels, i.e. belong in the denotations of their types. 

Note that the above types are restricted in that they can only be 
applied to finite arguments. In future work, we could address this 
issue with unrefined versions of primitive types that soundly allow 
operation on arbitrary arguments. For example, with the current 
type for +, addition of potentially diverging expressions is rejected. 


Thus, we could define an unrefined signature 

Ty(+) = x:Int —> y:Int -A Int 

and allow the two types of + to co-exist (as an intersection type), 
where the type checker would choose the precise refined type if and 
only if both of +’s arguments are finite. 

Diverging Fixpoints ( f ix T ) Next, note that the only place where 
divergence enters the picture is through the fixpoint combinators 
used to encode recursion. For any function or basic type r = Ti —> 
...—>■ r n , we define the result to be the type r„,. 

For each r whose result is a Div type, there is a diverging 
fixpoint combinator fix r , such that 

S{±ix T ,f) = f (f ix T /) 

Ty(fix-) m (r -A r) -A r 

i.e., fix T yields recursive functions of type r. Of course, fix r 
belongs in the denotation of its type l25l only if the result type is a 
Div type (and not when the result is a Wnf or Fin type). Thus, we 
restrict diverging fixpoints to functions with Div result types. 
Indexed Fixpoints (tf ix") For each type r whose result is a Fin 
type, we have a family of indexed fixpoints combinators tf ix": 
<3(tf ix", /) = Xm.f m (tfix™ /) 

Ty(tf ix") = (n:nat* -A r n -A r) -A r n 
where, t„ = {n:nat* | v < n} —V r 
t„ is a weakened version of r that can only be invoked on inputs 
smaller than n. Thus, we enforce termination by requiring that 
tfix" is only called with m that are strictly smaller than n. As 
the indices are well-founded nats, evaluation will terminate. 
Terminating Fixpoints (tf ix T ) Finally, we use the indexed com¬ 
binators to define the terminating fixpoint combinator tf ix T as: 
<5(tfi*r,/) = Xn.f n (tfix?/) 

Ty(tfiXr) = (n:nat* -> r n -A r) -a nat^ -A r 

Thus, the top-level call to the recursive function requires a nat' J 
parameter n that acts as a starting index, after which, all “recursive” 
calls are to combinators with smaller indices, ensuring termination. 
Example: Factorial Consider the factorial function: 

fac = An.A/.case _ = (n = 0) of 

Letr = nat - 1 . We prove termination by typing 
0 \~d tfix T fac : nat* -A r 


</("-!) . 


To understand why, note that tfix" is only called with arguments 
strictly smaller than n 

tfix T fac n >-A* fac n (tfix" fac) 

-A* n X (tfix" fac (n - 1)) 

A* n x (fac (n — 1) (tfix" -1 fac)) 

^A* tiXn-lX (tfix" -1 fac (n — 2)) 

A* nxti-lx ... x (tfix 1 fac 0) 

A* n X n — 1 X ... X (fac 0 (tfix° fac)) 
A* nxn—1X...X1 


Soundness of Stratification To formally prove that stratification is 
soundly enforced, it suffices to prove that the Denotation Lemma[2] 
holds for X D . This, in turn, boils down to proving that each (strati¬ 
fied) constant belongs in its type’s denotation, i.e. each c €. [Ty(c)J 
or that the Lemma [I] holds for X D . The crucial part of the above 
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is proving that the indexed and terminating fixpoints inhabit their 
types’ denotations. 

Theorem 3. [Fixpoint Typing] 

• fix,. £ [Ty(fix T )], 

• Vn.tfix" £ [Ty(tf ix”)], 

• tfix T £ [Ty(tfix r )|. 

With the above we can prove soundness of Stratification as a 
corollary Denotation Lemma [2] given the interpretations of the 
stratified types. 

Corollary 1. [Soundness of Stratification] 

1. 7jf0 b d e : t*, then evaluation ofe is finite. 

2. lf% bo e : r^, then e reduces to WHNF. 

3. 7jf0 b n e : {v:t \ p}, then p cannot diverge. 

Finally, as a direct implication the well-formedness rule WF- 
Base-D we conclude[3] i.e. that refinements cannot diverge. 

4.3 Verification With Stratified Types 

We put the pieces together to obtain an algorithmic implication rule 
X-Base-D instead of the undecidable X-Base (from Figure |4j. 
Intuitively, each closing substitution 9 corresponds to a set of logi¬ 
cal assignments (0|). Thus, we will translate V into logical formula 
OFD and denotation inclusion into logical implication such that: 

• 6 £ [TJ iff all o £ (]0[) satisfy (|r[), and 

• 6{v:B | pi} C 9{v:B | p 2 } iff all a £ Q0|) satisfy pi => p 2 . 

Translating Refinements & Environments To translate environ¬ 
ments into logical formulas, recall that 9 £ [r] iff for each x:t £ 
T, we have 9(x) £ [0(t)J. Thus, 

.,x n :r n D = (|a:i:riD A ... A flai„:TnD 
How should we translate a single binding? Since a binding denotes 
[{x:B | pfrj <k {e | if e M-* w then p \w/x\ M-* true} 
a direct translation would require a logical value predicate Val(a;), 
which we could use to obtain the logical translation 

d(a;:S|p}D =-A/al(a;)Vp 

This translation poses several theoretical and practical problems 
that preclude the use of existing SMT solvers (as detailed in ;|8j. 
However, our stratification guarantees (cf. (jTOJ, fi~T) ) that labeled 
types reduces to values, and so we can simply conservatively trans¬ 
late the Div and labeled (Wnf, Fin) bindings as: 

(\{x:B | p}D = true <\{x:B l | p}D = p 

Soundness We prove soundness by showing that the decidable 
implication X-Base-D approximates the undecidable X-BASE. 

Theorem 4. If (|rD => pi => p 2 is valid then 

T b u {v:B | p,} X {v:B | p 2 } 

To prove the above, let VC = (]rD => pi =$■ p 2 . We prove that 
if the VC is valid then T b u {v.b | pi} X {v:b | p 2 }. This fact 
relies crucially on a notion of tracking evaluation which allows us 
to reduce a closing substitution 9 to a lifted substitution 0 1 , written 
9 b 1 , after which we prove: 

Lemma 3. [Lifting] 9(e) e -A* c iff ^9 9 ± s.t. 9 ± (e) *-+* c. 

We combine the Lifting Lemma and the equivalence Theorem|2] 
to prove that the validity of the VC demonstrates the denotational 
containment V9 £ [r].[0({u:S | pi})] C [ 9({v:B | p^})]. The 
soundness of algorithmic typing follows from Theorems EHOD 


Theorem 5. [Soundness of \ D ] 

• Approximation: Ifli b d e : t then 0 \~u e : r. 

• Crash-Freedom: If 0 b d e : t then e f-r* crash. 

5. Implementation: LiquidHaskell 

We have implemented \ D in LiquidHaskell (^2|. Next, we 
describe the key steps in the transition from X° to Haskell. 

5.1 Termination 

Haskell’s recursive functions of type nat* —v r are represented, 
in GHC’s Core l30l as let rec / = A n.e which is operationally 
equivalent to let / = tf ix T (An. A/.e). Given the type of tfix r , 
checking that / has type nat^ —> r reduces to checking e in a 
termination-weakened environment where 

/ : (n:nat^ | „ < n} ^ r 

Thus, LiquidHaskell proves termination just as X D does: by 
checking the body in the above environment, where the recursive 
binder is called with nat inputs that are strictly smaller than n. 
Default Metric For example, LiquidHaskell proves that 

fac n = if n « f) then 1 else n * fac (n-1) 

has type nat^ —> nat^ by typechecking the body of fac in a 
termination-weakened environment fac : (v:nat^ | v < n} —V nat^ 
The recursive call generates the subtyping query: 

n:{0 < n}, -i(n = 0) bp> (v = n — 1} X (0 < v A v < n} 
Which reduces to the valid VC 

0<nA-'(n = 0)=b(v = n— l)=£>(0<vAv<n) 
proving that fac terminates, in essence because the first parameter 
forms a well-founded decreasing metric. 

Refinements Enable Termination Consider Euclid’s GCD: 

gcd :: a:Nat -> {v:Nat I v < a} -> Nat 
gcd a 0 = a 

gcd a b = gcd b (a 'mod' b) 

Here, the first parameter is decreasing, but this requires the fact that 
the second parameter is smaller than the first and that mod returns 
results smaller than its second parameter. Both facts are easily 
expressed as refinements, but elude non-extensible checkers fT5 1. 
Explicit Termination Metrics The indexed-fixpoint combinator 
technique is easily extended to cases where some parameter other 
than the first is the well-founded metric. For example, consider: 

tfac :: Nat -> n:Nat -> Nat / [n] 

tfac x a t b == 0 = x 

| otherwise = tfac (n*x) (n-1) 

We specify that the last parameter is decreasing by using an explicit 
termination metric / [n] in the type. LIQUIDHASKELL desugars 
the termination metric into a new nat-valued ghost parameter d 
whose value is always equal to the termination metric n: 

tfac :: d:Nat -> Nat -> {n:Nat I d = a) -> Nat 
tfac d x n 1 a ss 0 = x 

| otherwise tfac (n-1) (n*x) (n-1) 

Type checking, as before, checks the body in an environment where 
the first argument of tfac is weakened, i.e., requires proving d 
> n-1. So, the system needs to know that the ghost argument d 
represents the decreasing metric. We capture this information in the 
type signature of tfac where the last argument exactly specifies 
that d is the termination metric n, i.e., d = n. Note that since the 
termination metric can depend on any argument, it is important to 
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refine the last argument, so that all arguments are in scope, with the 
fact that d is the termination metric. 

To generalize, desugaring of termination metrics proceeds as 
follows. Let / be a recursive function with parameters x, and 
termination metric p(x). Then LiquidHaskell will 

• add a nat-valued ghost first parameter d in the definition of /, 

• weaken the last argument of / with the refinement d = p(x), 

• at each recursive call of / e, apply p(e) as the first argument. 

Explicit Termination Expressions Let us now apply the previous 
technique in a function where none of the parameters themselves 
decrease across recursive calls, but there is some expression that 
forms the decreasing metric. Consider range lo hi, which re¬ 
turns the list of ints from lo to hi: We generalize the explicit 
metric specification to expressions like hi-io, LiquidHaskell 
desugars the expression into a new nat-valued ghost parameter 
whose value is always equal to hi-lo, that is: 

range :: lo:Nat -> [hi:Nat I hi >= lo} -> [Natl 
/ [hi-lo] 

range lo hi | lo < hi = lo : range (lo + 1) hi 

Here, neither parameter is decreasing (indeed, the first one is in¬ 
creasing) but hi-lo decreases across each call. We generalize the 
explicit metric specification to expressions like hi-lo. Liquid¬ 
Haskell desugars the expression into a new nat-valued ghost 
parameter whose value is always equal to hi-lo, that is: 
range lo hi s go (hi-lo) lo hi 
where 

go :: d:Nat -> lo:Nat 

-> [hi:Nat | d = hi - lo} -> [Nat] 
go d lo hi 

I lo < hi = 1 : go (hi-(lo+l)) (lo+l) hi 
I _ |1 

After which, it proves go terminating, by showing that the first 
argument d is a nat that decreases across each recursive call. 
Recursion over Data Types The above strategy generalizes easily 
to functions that recurse over (finite) data structures like arrays, 
lists, and trees. In these cases, we simply use measures to project 
the structure onto nat, thereby reducing the verification to the 
previously seen cases. For each user defined type, e.g. 

data L [sz] a = N | C a (La) 
we can define a measure 

measure sz :: L a -> Nat 
sz N =0 

and use it as the decreasing metric to prove that map terminates: 

map :: (a -> b) -> xs:L a L b / [sz xs] 
map f (C x xs) = C (f x) (map f xs) 
map f N = N 

Generalized Metrics Over Datatypes Finally, in many functions 
there is no single argument whose (measure) provably decreases. 
For example, consider: 

merge :: xs:_ -> ys:_ -> _ / [sz xs + sz ys] 
merge (C x xs) (C y ys) 

| x < y = x 'C' (merge xs (y 'C' ys) ) 

I otherwise = y 'C' (merge (x 'C' xs) ys) 

from the homonymous sorting routine. Here, neither parameter 
decreases, but the sum of their sizes does. As before Liquid¬ 
Haskell desugars the decreasing expression into a ghost param¬ 
eter and thereby proves termination (assuming, of course, that the 
inputs were finite fists, i.e. a.) 


Automation: Default Size Measures Structural recursion on the 
first argument is a common pattern in Haskell code. LIQUID¬ 
HASKELL automates termination proofs for this common case, 
by allowing users to specify a size measure for each data type, (e.g. 
sz for L a). Now, if no termination metric is given, by default 
LiquidHaskell assumes that the first argument whose type has 
an associated size measure decreases. Thus, in the above, we need 
not specify metrics for f ac or gcd or map as the size measure is au¬ 
tomatically used to prove termination. This simple heuristic allows 
us to automatically prove 67% of recursive functions terminating. 

5.2 Non-termination 

By default, LiquidHaskell checks that every function is ter¬ 
minating. We show in ^6] that this is in fact the overwhelmingly 
common case in practice. However, annotating a function as lazy 
deactivates LiquidHaskell’s termination check (and marks the 
result as a Div type). This allows us to check functions that are non¬ 
terminating, and allows LiquidHaskell to prove safety prop¬ 
erties of programs that manipulate infinite data, such as streams, 
which arise idiomatically with Haskell’s lazy semantics. For exam¬ 
ple, consider the classic repeat function: 
repeat x = x 'C' repeat x 

We cannot use the tf ix combinators to represent this kind of recur¬ 
sion, and hence, use the non-terminating fix combinator instead. 

Let us see how we can use refinements to statically distinguish 
between finite and infinite streams. The direct, global route of using 
an inductively defined measure to describe infinite lists is unavail¬ 
able as such a measure, and hence, the corresponding refinement 
would be non-terminating. Instead, we describe infinite lists in lo¬ 
cal fashion, by stating that each tail is non-empty. 

Step 1: Abstract Refinements We can parametrize a datatype with 
abstract refinements that relate sub-parts of the structure 1531 . For 
example, we parameterize the fist type as: 

data L a <p :: L a -> Prop> 

= N | C a [v: L<p> a I (p v) } 

which parameterizes the fist with a refinement p which holds for 
each tail of the list, i.e. holds for each of the second arguments to 
the c constructor in each sub-fist. 

Step 2: Measuring Emptiness Now, we can write a measure that 
states when a list is empty 

measure emp :: L a -> Prop 
emp (C x xs) = false 

As described in ! |4] LiquidHaskell translates the abstract refine¬ 
ments and measures into refined types for n and c. 

Step 3: Specification & Verification Finally, we can use the abstract 
refinements and measures to write a type alias describing a refined 
version of L a representing infinite streams: 

type Stream a = 

(xs: \v -> not (emp v 

We can now type repeat as: 

lazy repeat :: a -> Stream 
repeat x = x 'C' repeat 

The lazy keyword deactivates termination checking, and marks 
the output as a Div type. Even more interestingly, we can prove 
safety properties of infinite fists, for example: 

take :: Nat -> Stream a -> L a 

take 0 _ = N 

take _ N = error "never happens" 
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LiquidHaskell proves, similar to the head example from '|2] 
that we never match a N when the input is a Stream. 

Finite vs. Infinite Lists Thus, the combination of refinements 
and labels allows our stratified type system to specify and ver¬ 
ify whether a list is finite or infinite. Note that: L 1 - 1 a represents 
finite lists i.e. those produced using the (inductive) terminating fix- 
point combinators, a represents (potentially) infinite lists which 
are guaranteed to reduce to values, i.e. non-diverging computations 
that yield finite or infinite fists, and L a represents computations 
that may diverge or produce a finite or infinite fist. 

6. Evaluation 

Our goal is to build a practical and effective SMT & refinement 
type-based verifier for Haskell. We have shown that lazy evalua¬ 
tion requires the verifier to reason about divergence; we have pro¬ 
posed an approach for implicitly reasoning about divergence by ea¬ 
gerly proving termination, thereby optimizing the precision of the 
verifier. Next, we describe an experimental evaluation of our ap¬ 
proach that uses LiquidHaskell to prove termination and func¬ 
tional correctness properties of a suite of widely used Haskell li¬ 
braries totaling more than 10KLOC. Our evaluation seeks to de¬ 
termine whether our approach is suitable for a lazy language (i.e. 
do most Haskell functions terminate?), precise enough to capture 
the termination reasons (i.e. is LiquidHaskell able to prove that 
most functions terminate?), usable without placing an unreason¬ 
ably high burden on the user in the form of explicit termination 
annotations, and effective enough to enable the verification of func¬ 
tional correctness properties. For brevity, we omit a description of 
the properties other than termination, please see f34l for details. 
Implementation LiquidHaskell takes as input: (1) A Haskell 
source file, (2) Refinement type specifications, including refined 
datatype definitions, measures, predicate and type aliases, and func¬ 
tion signatures, and (3) Predicate fragments called qualifiers which 
are used to infer refinement types using the abstract interpretation 
framework of Liquid Typing H6). The verifier returns as output, 
Safe or Unsafe, depending on whether the code meets the spec¬ 
ifications or not, and, importantly for debugging the code (or spec¬ 
ification!) the inferred types for all sub-expressions. 

Benchmarks As benchmarks, we used the following libraries: 
GHC.List and Data.List, which together implement many 
standard list operations, Data. Set. Splay, which implements 
an splay functional set. Data.Map.Base, which implements a 
functional map, Vector-Algorithms, which includes a suite 
of “imperative” array-based sorting algorithms. Bytestring, a 
library for manipulating byte arrays, and Text, a library for high- 
performance Unicode text processing. These benchmarks represent 
a wide spectrum of idiomatic Haskell codes: the first three are 
widely used libraries based on recursive data structures, the fourth 
and fifth perform subtle, low-level arithmetic manipulation of array 
indices and pointers, and the last is a rich, high-level library with 
sophisticated application-specific invariants, well outside the scope 
of even Haskell’s expressive type system. Thus, this suite provides a 
diverse and challenging test-bed for evaluating LiquidHaskell. 
Results Table [l] summarizes our experiments, which covered 39 
modules totaling 10,209 non-comment lines of source code. The 
results were collected on a machine with an Intel Xeon X5600 and 
32GB of RAM (no benchmark required more than 1GB). Timing 
data was for runs that performed full verification of safety and 
functional correctness properties in addition to termination. 

• Suitable: Our approach of eagerly proving termination is in 
fact, highly suitable: of the 504 recursive functions, only 12 
functions were actually non-terminating (i.e. non-inductive). 
That is, 97.6% of recursive functions are inductively defined. 



Table 1. A quantitative evaluation of our experiments. LOC is the number of non¬ 
comment lines of source code as reported by sloccount. Fun is the total number of 
functions in the hbrary. Rec is the number of recursive functions. Div is the number 
of functions marked as potentially non-terminating. Hint is the number of termination 
hints, in the form of termination expressions, given to LiquidHaskell. Time is the 
time, in seconds, required to run LiquidHaskell. 


• Precise: Our approach is extremely precise, as refinements pro¬ 
vide auxiliary invariants and extensibility that is crucial for 
proving termination. We successfully prove that 96.0% of re¬ 
cursive functions terminate. 

• Usable: Our approach is highly usable and only places a modest 
annotation burden on the user. The default metric, namely the 
first parameter with an associated size measure, suffices to 
automatically prove 65.7% of recursive functions terminating. 
Thus, only 34.3% require explicit termination metric, totaling 
about 1.7 witnesses (about 1 line each) per 100 lines of code. 

• Effective: Our approach is extremely effective at improving the 
precision of the overall verifier (by allowing the VC to use 
facts about binders that provably reduce to values.) Without 
the termination optimization, i.e. by only using information for 
matched-binders (thus in WHNF), LiquidHaskell reports 
1,395 unique functional correctness warnings - about 1 per 7 
lines. With termination information, this number goes to zero. 

7. Related Work 

Next we situate our work with closely related lines of research. 
Dependent Types are the basis of many verifiers, or more generally, 
proof assistants. In this setting arbitrary terms may appear inside 
types, so to prevent logical inconsistencies, and enable the checking 
of type equivalence, all terms must terminate. “Full” dependently 
typed systems like Coq O, Agda (24), and Idris m typically 
use structural checks where recursion is allowed on sub-terms of 
ADTs to ensure that all terms terminate. We differ in that, since the 
refinement logic is restricted, we do not require that all functions 
terminate, and hence, we can prove properties of possibly diverging 
functions like collatz as well as lazy functions like repeat. 
Recent languages like Aura fl8l and Zombie QD allow general 
recursion, but constrain the logic to a terminating sublanguage, as 
we do, to avoid reasoning about divergence in the logic. In contrast 
to us, the above systems crucially assume call-by-value semantics 
to ensure that binders are bound to values, i.e. cannot diverge. 
Refinement Types are a form of dependent types where invariants 
are encoded via a combination of types and predicates from a re¬ 
stricted SMT-decidable logic 0(1311171137). The restriction makes 
it safe to support arbitrary recursion, which has hitherto never been 
a problem for refinement types. However, we show that this is be¬ 
cause all the above systems implicitly assume that all free variables 
are bound to values, which is only guaranteed under CBV and, as 
we have seen, leads to unsoundness under lazy evaluation. 
Tracking Divergent Computations The notion of type stratification 
to track potentially diverging computations dates to at least fTol 
which uses f to encode diverging terms, and types f ix as (f —>• 
f) —>■ -f). More recently, m tracks diverging computations within 
a partiality monad. Unlike the above, we use refinements to obtain 
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terminating fixpoints (tf ix), which let us prove the vast majority 
(of sub-expressions) in real world libraries as non-diverging, avoid¬ 
ing the restructuring that would be required by the partiality monad. 
Termination Analyses Various authors have proposed techniques 
to verify termination of recursive functions, either using the “size- 
change principle” GSEOD, or by annotating types with size indices 
and verifying that the arguments of recursive calls have smaller in¬ 
dices |2][T7]. Our use of refinements to encode terminating fix- 
points is most closely related to (36), but this work also crucially 
assumes CBV semantics for soundness. 

AProVE Q3 implements a powerful, fully-automatic termina¬ 
tion analysis for Haskell based on term-rewriting. While we could 
use an external analysis like AProVE, we have found that encod¬ 
ing the termination proof via refinements provided advantages that 
are crucial in large, real-world code bases. Specifically, refinements 
let us (1) prove termination over a subset (not all) of inputs; many 
functions (e.g. fac) terminate only on Nat inputs and not all int 
s, (2) encode pre-conditions, post-conditions, and auxiliary invari¬ 
ants that are essential for proving termination, ( e.g. gcd), (3) eas¬ 
ily specify non-standard decreasing metrics and prove termination, 
(e.g. range). In each case, the code could be (significantly) rewrit¬ 
ten to be amenable to AProVE but this defeats the purpose of an 
automatic checker. Finally, none of the above analyses have been 
empirically evaluated on large and complex real-world libraries. 
Static Contract Checkers like ESCJava fi~4l are a classical way 
of verifying correctness through assertions and pre- and post¬ 
conditions. Side-effects like modifications of global variables are 
a well known issue for static checkers for imperative languages; 
the standard approach is to use an effect analysis to determine the 
“modifies clause” i.e. the set of globals modified by a procedure. 
Similarly, one can view our approach as implicitly computing the 
non-termination effects. Il38l describes a static contract checker for 
Haskell that uses symbolic execution to unroll procedures upto 
some fixed depth, yielding weaker “bounded” soundness guar¬ 
antees. Similarly, Zeno m is an automatic Haskell prover that 
combines unrolling with heuristics for rewriting and proof-search. 
Based on rewriting, it is sound but “Zeno might loop forever” when 
faced with non-termination. Finally, the Halo l35l contract checker 
encodes Haskell programs into first-order logic by directly mod¬ 
eling the code’s denotational semantics, again, requiring heuris¬ 
tics for instantiating axioms describing functions’ behavior. Halo’s 
translation of Haskell programs directly encodes constructors as 
uninterpreted functions, axiomatized to be injective (as the denota¬ 
tional semantics requires). This heavyweight encoding is more pre¬ 
cise than predicate abstraction but leads to model-theoretic prob¬ 
lems (outlined in the Halo paper) and affects the efficiency of the 
encoding when scaling to larger programs (see also [8] paragraph 
B) in the lack of specialized decisions procedures. Unlike any of 
the above, our type-based approach does not rely on heuristics for 
unrolling recursive procedures, or instantiating axioms. Instead we 
are based on decidable SMT validity checking and abstract inter¬ 
pretation do which makes the tool predictable and the overall 
workflow scale to the verification of large, real-world code bases. 

8. Conclusions & Future Work 

Our goal is to use the recent advances in SMT solving to build 
automated refinement type-based verifiers for Haskell. In this pa¬ 
per, we have made the following advances towards the goal. First, 
we demonstrated how the classical technique for generating VCs 
from refinement subtyping queries is unsound under lazy evalu¬ 
ation. Second, we have presented a solution that addresses the un¬ 
soundness by stratifying types into those that are inhabited by terms 
that may diverge, those that must reduce to Haskell values, and 
those that must reduce to finite values, and have shown how refine¬ 


ment types may themselves be used to soundly verify the stratifica¬ 
tion. Third, we have developed an implementation of our technique 
in LiquidHaskell and have evaluated the tool on a large corpus 
comprising 10KLOC of widely used Haskell libraries. Our exper¬ 
iments empirically demonstrate the practical effectiveness of our 
approach: using refinement types, we were able to prove 96% of 
recursive functions as terminating, and to crucially use this infor¬ 
mation to prove a variety of functional correctness properties. 
Limitations While our approach is demonstrably effective in prac¬ 
tice, it relies critically on proving termination, which, while inde¬ 
pendently useful, is not wholly satisfying in theory, as adding di¬ 
vergence shouldn’t break a safety proof. Our system can prove a 
program safe, but if the program is modified by making some func¬ 
tions non-deterministically diverge, then, we may no longer be able 
to prove safety. Thus, in future work, it would be valuable to ex¬ 
plore other ways to reconcile laziness and refinement typing. We 
outline some routes and the challenging obstacles along them. 

A. Convert Lazy To Eager Evaluation One alternative might be to 
translate the program from lazy to eager evaluation, for example, to 
replace every (thunk) e with an abstraction A().e, and every use of 
a lazy value x with an application x (). After this, we could simply 
assume eager evaluation, and so the usual refinement type systems 
could be used to verify Haskell. Alas, no. While sound, this transla¬ 
tion doesn’t solve the problem of reasoning about divergence. A de¬ 
pendent function type a::Int — y {u:Int | v > x} would be trans¬ 
formed to a::(() —y Int) —y {u:Int | v > x ()} The transformed 
type is problematic as it uses arbitrary function applications in the 
refinement logic! The type is only sensible if x () provably reduces 
to a value, bringing us back to square one. 

B. Explicit Reasoning about Divergence Another alternative is to 
enrich the refinement logic with a value predicate Val(a;) that is 
true when “x is a value” and use the SMT solver to explicitly rea¬ 
son about divergence. (Note that Val(a;) is equivalent to introducing 
a _L constant denoting divergence, and writing (x $6 A).) Unfortu¬ 
nately, this Val(a:) predicate takes the VCs outside the scope of the 
standard efficiently decidable logics supported by SMT solvers. To 
see why, recall the subtyping query from good in t|2] With explicit 
value predicates, this subtyping reduces to the VC: 


(Val(a;) =* x > 0) 
(Val(y) =► y > 0) 


=>{*=V + 1) =>(«><>) 


( 12 ) 


To prove the above valid, we require the knowledge that (v = j/+l) 
implies that y is a value, i.e. that Val(y) holds. This fact, while 
obvious to a human reader, is outside the decidable theories of 
linear arithmetic of the existing SMT solvers. Thus, existing solvers 
would be unable to prove valid, causing us to reject good. 
Possible Fix: Explicit Reasoning With Axioms? One possible fix 
for the above would be to specify a collection of axioms that 
characterize how the value predicate behaves with respect to the 
other theory operators. For example, we might specify axioms like: 


Vx,y,z.(x = y + z) =» (Vai(at) A Val(t/) A Val(z)) 
V®, y.(x < y) =» (Val(x) AVal(y)) 


etc.. However, this is a non-solution for several reasons. First, it 
is not clear what a complete set of axioms is. Second, there is the 
well known loss of predictable checking that arises when using ax¬ 
ioms, as one must rely on various brittle, syntactic matching and 
instantiation heuristics m . It is unclear how well these heuristics 
will work with the sophisticated linear programming-based algo¬ 
rithms used to decide arithmetic theories. Thus, proper support for 
value predicates could require significant changes to existing deci¬ 
sion procedures, making it impossible to use existing SMT solvers. 
Possible Fix: Explicit Reasoning With Types? Another possible fix 
would be to encode the behavior of the value predicates within the 
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refinement types for different operators, after which the predicate 
itself could be treated as an uninterpreted function in the refinement 
logic (6). For instance, we could type the primitives: 

-> (v | t = x + y && Val x && Val y} 

-> {v I v <=> x < y && Val X ss Val y} 

While this approach requires no changes to the SMT machinery, it 
makes specifications complex and verbose. We cannot just add the 
value predicates to the primitives’ specifications. Consider 
choose b x y = if b then x+1 else y+2 
To reason about the output of choose we must type it as: 

choose :: Bool -> x:Int -> y:Int 

-> {v|(v > x S& Val x)||(v > y SS Val y> j 

Thus, the value predicates will pervasively clutter all signatures 
with strictness information, making the system unpleasant to use. 
Divergence Requires 3-Valued Logic Finally, for either “fix”, the 
value predicate poses a model-theoretic problem: what is the mean¬ 
ing of Val (a;)? One sensible approach is to extend the universe with 
a family of distinct _L constants, such that Val(_L) is false. These 
constants lead inevitably into a three-valued logic (in order to give 
meaning to formulas like _L S».jL). Thus, even if we were to find 
a way to reason with the value predicate via axioms or types, we 
would have to ensure that we properly handled the 3-valued logic 
within existing 2-valued SMT solvers. 

Future Work Thus, in future work it would be worthwhile to ad¬ 
dress the above technical and usability problems to enable explicit 
reasoning with the value predicate. This explicit system would 
be more expressive than our stratified approach, e.g. would let 
us check let x = collatz 10 in 12 Miv ' x+1 by encod¬ 
ing strictness inside the logic. Nevertheless, we suspect such a ver¬ 
ifier would use stratification to eliminate the value predicate in the 
common case. At any rate, until these hurdles are crossed, we can 
take comfort in stratified refinement types and can just eagerly use 
termination to prove safety for lazy languages. 
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